Не секрет, что являясь конкурентами в плане технологий виртуализации, компании VMware и Microsoft также ведут и сотрудничество. Как раз результатом такого сотрудничества и стала интеграция драйверов VMware Paravirtual SCSI controller (PVSCSI) в операционную систему Microsoft Windows 11, начиная с версии 2H22 (выпущена 20 сентября этого года).

Раньше при установке гостевой ОС в виртуальной машине на дисках PVSCSI система Windows просто не видела диски на этом контроллере, поэтому установить ее на них было нельзя. Теперь же на шаге обнаружения диска и сетевых устройств (виртуальный сетевой адаптер с драйверов VMware VMXNET3) вы можете их увидеть в рамках рабочего процесса Windows Out of Box Experience (OOBE):

Между тем, это вовсе не значит, что после установки операционной системы вы не должны устанавливать пакет VMware Tools. Его обязательно нужно поставить, так как он содержит не только драйверы устройств, но и другие важные вспомогательные инструменты.

Также драйверы VMware Paravirtual SCSI и VMware VMXNET3 теперь включены в обновления Windows Updates:

Для получения более подробной информации об интеграции службы обновлений Windows и драйверов VMware вы можете воспользоваться статьей KB 82290 или поиском в Microsoft Update Catalog.

В конце лета этого года компания VMware провела конференцию Explore 2022, где представила новую версию решения для создания отказоустойчивых хранилищ VMware vSAN 8. Главным нововведением обновленной платформы стала архитектура Express Storage Architecture (ESA), которая позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения. Сегодня мы посмотрим, какие улучшения механизма работы снапшотов появились в vSAN, работающем в ESA-варианте.

Еще много лет назад мы писали о том, что снапшоты - это зло, и использовать их нужно с большой осторожностью и при большой необходимости. Например, перед обновлением виртуального аппаратного обеспечения, ОС или критичных приложений можно сделать снапшот, проверить что все в порядке после обновления, а затем удалить его.

Снапшоты, создаваемые для специфических целей администраторов, часто разрастаются в разных ветках, что в итоге приводит к падению производительности виртуальной машины и операционным сложностям при консолидации (например, недостаток места). При этом снапшоты - это вещь нужная для таких процессов, как резервное копирование и автоматизированные рабочие процессы Continuous Integration/Continuous Delivery (CI/CD), Copy Data Management (CDM), а также управление виртуальными ПК VMware Horizon.

Часто в большой инфраструктуре VMware vSphere можно обязательно найти вот такую машину, которая "почему-то тормозит":

Традиционно снапшоты в VMware vSphere строились на базе технологии redo-log (дельта диск отличий от основного VMDK), которая имеет ограничения по масштабируемости и производительности. Снапшоты типа VMFSsparse использовались по умолчанию в файловой системе VMFS5 для дисков менее 2 ТБ и для всех дисков на системах до VMFS5.

VMFSsparse работает поверх VMFS как redo-log, который создается пустым, как только для ВМ создается снапшот, и растет до размера родительского VMDK-диска, накапливая данные. Начиная с VMFS5, для дисков более 2 ТБ и для всех дисков VMFS6 был добавлен формат снапшота VMFS SEsparse. Это эволюционное изменение снапшотов, которое давало улучшения в плане склеивания снапшотов и в отношении их больших цепочек, где ранее происходила потеря производительности.

Также для SEsparse снапшотов было сделано множество улучшений в новых версиях vSphere, например, при чтении данных для машин со снапшотами была существенно увеличена производительность: чтение идет сразу из нужного VMDK, минуя всю цепочку снапшотов при каждом обращении, в отличие от того, как это было сделано раньше. Все это снижает latency на чтение:

Также были сделаны некоторые оптимизации "подмораживания" (stun) при различного рода операциях со снапшотами, а также специфические технологии, такие как Mirror driver, но концептуально суть снапшотов не поменялась. Поэтому VMware продолжала давать рекомендации не хранить их более 48 часов и не создавать длинных цепочек снапшотов, особенно для критичных нагрузок.

Архитектура снапшотов в vSAN базируется на традиционных redo-log снапшотах, которые были доработаны - так появился формат vsanSparse (начиная с vSAN 6). Он использует механизм redirect-on-write и снижает некоторые технические ограничения снапшотов за счет кэширования, но проблемы подмораживания и долгого времени удаления снапшотов остаются.

В новой версии vSAN 8 при использовании архитектуры ESA, снапшоты используются совершенно другим образом, нежели в прошлых версиях платформы. Вместо использования традиционной цепочки базового и дельта-дисков, механизм снапшотов использует lookup table, применяя структуры B-Tree.

Файловая система log structured file system в vSAN ESA позволяет новым операциям записи помещаться в новые сегменты хранилища с их указателями метаданных, интеллектуально размещая их в соответствии с принадлежностью к снапшотам. В этом случае время удаления снапшота снижается более чем в 100 раз по сравнению с прошлыми версиями платформы vSAN.

Также новая архитектура снапшотов снижает и накладные расходы на вычисления и перемещения данных, которые происходят при удалении снапшотов (а это были одни из самых нагружающих инфраструктуру операций). По-сути, когда в vSAN 8 удаляется снапшот, происходит лишь удаление метаданных, а физического перемещения блоков не происходит.

Мало того, пользователь получает подтверждение удаления снапшота сразу же, а удаление данных и метаданных происходит позже, в асинхронном режиме. Новая архитектура снапшотов ESA позволяет использовать практически неограниченное количество снапшотов - однако текущие параметры платформы vSphere ограничивают число снапшотов числом 32 на один объект.

Как знают администраторы VMware vSphere, решения для резервного копирования используют снапшоты через vSphere Storage API (также называемые VADP) для передачи резервных копий на хранилища. Новая функциональность vSAN ESA автоматически заменит старый механизм снапшотов, а пользователи увидят реальный прирост производительности при консолидации снапшотов, а также при работе продуктов VMware SRM и vSphere Replication в кластерах ESA.

Вчера мы писали о новых возможностях поддержки vVols в платформе VMware vSphere 8, анонсированные на конференции VMware Explore 2022. В то же время, с точки зрения хранилищ в платформе VMware vSphere 8 появилось еще несколько улучшений, о которых мы сегодня расскажем.

1. Улучшения возврата емкостей в хранилище (Space Reclamation)

Теперь минимально доступная скорость возврата (reclamation rate) уменьшена до 10 MBPS. Еще в vSphere 6.7 появилась функция регулировки скорости возврата (Space Reclamation, он же UNMAP) емкостей от платформы vSphere на сторону хранилища. Но даже на минимальной скорости 25 MBPS при одновременном выполнении команд доступа хостов к хранилищам происходили сбои из-за нагрузки и падение производительности, поэтому администраторам дали возможность снизить ее до 10 MBPS на уровне датастора.

Также теперь появилась выделенная очередь исполнения команд UNMAP для выскоприоритетных операций ввода-вывода метаданных VMFS. Это сделано для того, чтобы важные и первоочередные операции не затерялись в общем трафике UNMAP-команд.

2. Контейнерные хранилища CNS/CSI

Теперь для хранилищ CNS/Tanzu доступны политики хранилищ SPBM - EZT, LZT или Thin provisioning. Это позволит движку SPBM поддерживать создание и изменение правил политик, чтобы определить опции выделения томов. Также это упростит проверки комплаенса политик SPBM в отношении правил выделения томов.

• Для виртуальных дисков поддерживаются следующие операции: create, reconfigure, clone и relocate
• Для FCD-устройств поддерживаются: create, update storage policy, clone и relocate

3. Улучшения работы с NFS-хранилищами

Здесь были добавлены следующие функции для повышения надежности и стабильности:

• Повторная попытка монтирования томов при сбоях (Retry NFS mounts on failure)
• Валидация правильности монтирования томов (NFS mount validation)

Более подробно о нововведениях VMware vSphere 8 в плане хранилищ рассказано вот в этой статье.

На конференции Explore 2022 компания VMware объявила о выпуске новой версии платформы VMware vSphere 8, о возможностях которой мы уже писали. Сегодня мы посмотрим, что нового появилось в механизме работы томов vVols, которые позволяют более гибко подходить к хранению объектов виртуальных машин за счет передачи некоторых функций работы с их данными на сторону хранилищ.

Сегодня мы поговорим о нововведениях, которые появились в технологии vVols для восьмой версии платформы.

1. Поддержка технологии NVMe-oF

Это большое нововведение означает поддержку томами vVols на платформе vSphere 8 технологии NVMe-oF. В новой спецификации vVols появились определения vSphere API для механики работы с хранилищами VASA (vSphere Storage APIs for Storage Awareness) 4.0.

Напомним, что NVMe-oF - это реализация технологии RDMA, которая позволяет не использовать CPU для удаленного доступа к памяти и пропускать к хранилищу основной поток управляющих команд и команд доступа к данным напрямую, минуя процессоры серверов и ядро операционной системы. Еще один его плюс - это то, что он обратно совместим с такими технологиями, как InfiniBand, RoCE и iWARP. Для всего этого нужна поддержка RDMA со стороны HBA-адаптера хоста ESXi.

NVMe-oF имеет преимущество в виде меньших задержек (latency) над традиционным интерфейсом SCSI. Эта технология изначально предназначена для флэш-памяти и позволяет подключать all-flash NVMe дисковые массивы с очень высокой производительностью.

В рамках технологии NVMe-oF vVols каждый объект vVol становится пространством имен NVMe Namespace. Эти пространства имен группируются в ANA group (Asymmetrical Namespace Access). Многие команды проходят как In-Band для более эффективной коммуникации между хостами ESXi и дисковыми массивами.

Также упростилась настройка томов, в том числе NVMe с технологией vVols. При развертывании NVMe в vCenter, когда зарегистрирован VASA-провайдер, оставшаяся установка происходит в фоновом режиме, а обнаружение NVMe-контроллеров происходит автоматически. Как только создается датастор, объекты vPE (virtual Protocol Endpoints) и само соединение подхватываются и обрабатываются автоматически.

2. Дополнительные улучшения vVols NVMe-oF

Они включают в себя следующее:

• Поддержка до 256 пространств имен и 2000 путей
• Расширенная поддержка механизма резерваций для устройств NVMe - это позволит поддерживать функцию Clustered VMDK для кластеризованных приложений, таких как Microsoft WSFC на базе хранилищ NVMe-oF 
• Функции автообнаружения в механизме NVMe Discovery Services для ESXi при использовании NVMe-TCP для обнаружения контроллеров NVMe

3. Прочие улучшения

• Улучшение VM swap - уменьшенное время при включении и выключении для обеспечения лучшего быстродействия vMotion
• Улучшенная производительность компонента config-vVol - убраны задержки при обращения виртуальных машин к платформе ESXi

Компания NAKIVO выпустила обновление решения Backup & Replication v10.7, предназначенного для резервного копирования и репликации виртуальных машин в инфраструктуре VMware vSphere и Microsoft Hyper-V.

Давайте посмотрим, что нового в NAKIVO Backup & Replication v10.7:

• Backup to Azure Blob - теперь сами резервные копии и копии этих копий могут храниться в облачном блочном хранилище Azure Blob. Также для этого способа бэкапа поддерживаются функции immutability, то есть неизменяемость созданных копий.
• Backup to Backblaze B2 - теперь возможно резервное копирование в это облачное хранилище с обеспечением всех Enterprise-возможностей и функций immutability для защиты от ransomware.
• Microsoft Teams Backup - пользователям стала доступна защита данных инфраструктуры контента Microsoft Teams. Теперь можно сохранять и восстанавливать различные типы объектов, такие как каналы, посты и файлы для обеспечения непрерывности бизнеса.
• Wasabi Immutability - для этого типа хранилищ стали доступны функции immutability для защиты от ransomware на период, который определяется пользователем.
• Native Microsoft 365 Change Tracking - теперь для инфраструктуры Microsoft 365 работает технология быстрого создания инкрементальных бэкапов за счет интеграции с нативной технологией Microsoft для отслеживания изменяющихся блоков.
• Overview Dashboard - был добавлен дэшборд, на котором в реальном времени показываются основные параметры вашей бэкап-инфраструктуры, а также доступны функции для быстрого доступа к функциональности для защиты данных корпоративного датацентра.

Загрузить бесплатную пробную версию NAKIVO Backup & Replication v10.7 можно по этой ссылке.

Много лет назад мы писали о технологиях работы кэша write-through и write-back в ведущем на рынке виртуализации хранилищ решении StarWind Virtual SAN. С тех пор механика работы этих технологий была улучшена, но принципы остались теми же, как и большинство фундаментальных технологий. Сегодня мы поговорим о работе кэшей уровней L1 и L2, которые существенно улучшают быстродействие операций ввода-вывода.

При работе StarWind Virtual SAN с хранилищами используется кэш первого уровня (L1), располагающийся в оперативной памяти, а также кэш второго уровня (L2), размещенный на SSD-дисках, обеспечивающих высокое быстродействие системы.

StarWind использует традиционную оперативную память серверов (RAM) как буфер на чтение (write buffer) и L1-кэш, чтобы кэшировать операции записи, флэш-память SSD уже обслуживает кэш уровня L2. Оба кэша используют одни и те же алгоритмы - shared library, поэтому информация ниже применима, в основном, к кэшам обоих уровней. Об их отличиях мы также поговорим в статье отдельно.

При переполнении кэша нужно освободить его, используя какой-то алгоритм. StarWind применяет для этого алгоритм LRU - least recently used, то есть вытесняются данные (блоки), которые используются реже всего в последнее время.

В зависимости от степени исчерпания состояния кэша, его блоки могут находиться в одном из трех состояний: dirty, clean и empty. В самом начале блок помечается как empty - в нем нет данных, то есть блоки кэша не ассоциированы с блоками на диске. При работе кэша эти данные начинают заполняться. Блок помечается как dirty - если полезные данные были записаны в него, но еще не были записаны на диск (он не подтвердил запись данных). Блок помечается как clean, если данные из кэша были записаны на диск, либо блок кэша был записан в результате чтения в кэш блока с диска - то есть блок кэша и блок на диске содержат одинаковые данные.

Помните, что стандартный размер блока для кэша - 64 КБ.

Следующее полезное понятие - это прогрев кэша (cache warm-up). Эта концепция имплементируется на нижнем уровне в рамках сценария "in-memory" файловой системы LSFS (log-structured file system). Данные в кэш в этом случае попадают с диска, с учетом самых последних данных, записанных на диск.

Политики кэширования

Политика кэширования определяется вместе с другими параметрами кэша / устройств, когда они создаются. В StarWind Version 8 Release 5 режим работы кэша может быть изменен на лету для уже существующих устройств.

Write-back caching

Это режим, когда запись данных производится в кэш, но операция ввода-вывода (I/O) подтверждается, как запись на диск. Запись в основную память производится позже (при вытеснении или по истечению времени), группируя в одной операции несколько операций записи в соседние ячейки. Этот тип кэширования существенно ускоряет скорость записи данных на диск, однако имеет несколько меньшую надежность с точки зрения записи данных.

Если блок находится в статусе empty или clean, то запись в кэш происходит практически мгновенно, на уровне скорости записи данных в RAM или на SSD. А вот как работает кэш в разных обстоятельствах:

• Если операции записи не были сделаны в dirty-кэш на протяжении некоторого времени (по умолчанию 5 секунд), то данные записываются на диск. Блок переходит в состоянии clean, но данные в нем остаются.
• Если все доступные блоки кэша находятся в состоянии dirty, то данные, хранимые в самых старых блоках, форсированно скидываются на диск, а новые данные записываются в эти блоки. В этом случае производительность кэша несколько падает из-за требующихся операций записи на диск, и она сравнима со скоростью такой операции с диском.
• Если происходит сбой в работе сервера или памяти (или его выключают на обслуживание), то данные в кэше write-back, помеченные как dirty, немедленно сбрасываются на диск. Если размер кэша большой (гигабайты), то эта операция может занять значительное время. Его можно оценить так: Flushing time = cache size / RAM write.

Политика кэширования write-back ускоряет производительность в следующих случаях:

• Флуктуации нагрузки - кэш позволяет сгладить пики нагрузки за счет аккумуляции большого числа записей в кэше во время всплесков до момента снижения нагрузки.
• Постоянная перезапись тех же самых блоков - в этом случае они постоянно перезаписываются только в кэше, а на диск сбрасываются пачки блоков по мере необходимости.

Помните, что политика write-back предпочтительна для L1-кэша и в данный момент недоступна для L2-кэша, который всегда создается в режиме write-through.

Write-through caching

Это режим, когда запись производится непосредственно в основную память и дублируется в кэш. Такой тип кэширования не ускоряет запись данных на диск (но и не замедляет), но существенно увеличивает скорость чтения данных, которые можно взять из кэша. Этот тип кэша безопасен с точки зрения надежности данных и дает однозначный выигрыш в производительности.

При использовании этого типа кэширования не будет потери данных в случае неисправности сервера и памяти. Блоки памяти кэша в этом случае всегда помечены как clean.

Рекомендации по использованию кэша

L1 Cache

Он решает следующие проблемы:

• Запросы партнерского узла StarWind Virtual SAN могут приходить с небольшой задержкой и изменять порядок доступа к блокам, например, 1-2-3-4-5-6-7-8 изменится на 1-3-2-4-5-7-6-8. В этом случае L1- кэш сгладит поток последовательных запросов на запись с применением алгоритма round robin в дополнение к кэшированию. L1-кэш объединяет маленькие запросы записи в большие (write coalescing). Например, 16 запросов по 4k в кэш будут записаны на диск как единый блок 64к, что работает гораздо быстрее. Поэтому для такого кэша не нужно много памяти - от 128 МБ.
• L1 также компенсирует перезапись в те же секторы диска. Самая частая перезапись - это небольшие по размеру операции. Размер кэша должен зависеть от от частоты перезаписи данных и размера working data set. Чем чаще перезапись, теперь меньше вы можете делать кэш, но если больше размер working data set, то должен быть и больше кэш. В этом случае работает формула Tcached = Tdisk * (1 – (cache size) / (working set size)). В этом случае, если у вас кэш составляет 0.1 от data working set, процессинг данных будет составлять 0.9 от времени процессинга данных на диск. Если же cache size = working data set, то средний процессинг команд будет примерно равен времени процессинга команд в памяти.

StarWind L1 cache в режимах write-back и write-through может быть использован для:  

• Файловых устройств StarWind HA image file на базе HDD-хранилищ в конфигурации RAID 10.  
• Устройств StarWind LSFS на базе HDD в конфигурациях RAID 5, 6, 50, 60. Также посмотриите статью о требованиях устройств LSFS.

Также помните, что в большинстве случаев для дисковых массивов all-flash кэш уровня L1 вам не потребуется.

В идеале размер кэша L1 должен быть равен размеру working data set. Также размер кэша L1 влияет на время, которое вам потребуется, чтобы выключить сервер (нужно сбросить грязные блоки на диск). Также помните, что лучше не делать L1 кэш в режиме WB, чтобы не создавать ситуацию, когда большой объем данных может быть утерян.

При использовании кэша L1 в режиме write-back обязательно используйте UPS для серверов, чтобы не потерять часть данных. Время работы UPS должно позволяет сбросить содержимое грязного кэша на диск.

L2 Cache (Flash Cache)

Для обслуживания кэша L2 создается обычное устройство ImageFile device. У этого устройства нет таргета, и оно соединено с системой точно так же, как и устройство с данными (ImageFile or LSFS).

Система с кэшем L2 должна иметь больше оперативной памяти RAM для обеспечения накладных расходов. Формула тут такая: 6.5 ГБ RAM на 1 ТБ кэша L2, чтобы хранить метаданные. Более подробно о кэше L2 можно почитать в базе знаний StarWind.

StarWind L2 cache может быть использован для следующих сценариев:

• HA-устройства StarWind image file на базе HDD в конфигурации RAID 10.
• Устройства StarWind LSFS на базе HDD в конфигурации RAID 5, 6, 50, 60.
• HA-устройства StarWind image file на all-flash хранилищах в некоторых сценариях. Более подробно об этих сценариях можно почитать в базе знаний StarWind.

В большинстве случаев, когда у вас есть L1 кэш, кэш уровня L2 вам не потребуется. Размер L2 кэша должен быть равен среднему объему уникальных данных, запрашиваемых с хранилища на регулярной основе (определяется экспериментально).

На конференции VMware Explore 2022 компания VMware объявила о выпуске решения для организации отказоустойчивых кластеров виртуальных хранилищ VMware vSAN 8. Напомним, что прошлая мажорная версия VMware vSAN 7 была выпущена в марте 2020 года. Вчера мы писали о новых возможностях VMware vSphere 8, а сегодня поговорим о решении vSAN 8, которое очень тесно интегрировано с vSphere.

Итак, что нового появилось в VMware vSAN 8.0:

Новая архитектура vSAN Express Storage Architecture

В vSAN 8 появилась новая архитектура гиперконвергентной инфраструктуры vSAN Express Storage Architecture (ESA). Она позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.

С помощью флэш-памяти TLC на основе технологии NVMe, архитектура ESA имеет множество преимуществ со стандартной vSAN Original Storage Architecture (OSA), которая также продолжит поддерживаться для стандартного на текущий момент оборудования (устройства SATA/SAS).

Ключевыми структурными особенностями vSAN 8 ESA является переработанная и запатенованная файловая система (log-structured file system, LFS), новый оптимизированный для записи менеджер объектов (log-structured object manager), а также новый формат дисковых объектов.

Эти технологии позволяют добиться такого уровня производительности, где практически не происходит потерь на поддержание слоя виртуализации.

Новые возможности ESA дают преимущества в следующих аспектах:

1. Performance without tradeoff

Здесь есть два основных момента, существенно увеличивающих производительность:

• Изменение структуры хранения и обработки данных для алгоритмов RAID 5/6 erasure coding. Теперь производительность RAID 5/6 близка к таковой на базе RAID-1. За счет LFS и нового формата дисковых объектов обеспечивается высокая интеграция данных и устойчивость к отказам при сохранении высокой скорости канала чтения-записи.
• Intelligent I/O traffic management для сетевого трафика vSAN - теперь скорость процессинга трафика ввода-вывода близка к нативной для используемых устройств. Это достигается, в том числе, за счет адаптивной приоритизации трафика и его отсылки в моменты наименьшей загрузки канала.

2. Supreme resource and space efficiency

Адаптивный алгоритм обработки данных на RAID-5, который проверяет количество хостов в кластере и выбирает оптимальный способ размещения данных (работает, начиная с трех хостов). vSAN ESA также имеет возможности обнаружения изменений хостов, что влечет за собой ревизию структур данных RAID-5 и изменения политик размещения данных. В этом случае RAID-5 использует меньше сырой емкости хранилищ при сохранении надежности и управляемости.

Кликните на картинку, чтобы открыть анимацию:

Также были полностью переработаны механизмы сжатия данных, чтобы оптимизировать загрузку сети и нагрузку на CPU. Компрессия включена по умолчанию, и ее настройки можно изменять на уровне отдельных виртуальных машин с помощью политик хранилищ, вместо изменения конфигурации на уровне кластера.

Нажмите на картинку для открытия анимации:

Новый метод сжатия дает до 4x улучшение для каждого блока размером 4KB, если сравнивать с Original Storage Architecture. Также нагрузка на CPU существенно меньше у ESA, чем у OSA.

Шифрование данных также происходит теперь на верхних слоях ядра vSAN. Поскольку шифрование проводится для уже сжатых данных, то процесс шифрования происходит только однажды, что означает, что потоки данных между хостами также зашифрованы. Это позволяет избавиться от лишних шагов decrypt/encrypt и дает меньше нагрузки на CPU и сеть, освобождая ресурсы на поддержание работы виртуальных машин.

3. Intuitive, agile operations

Здесь два основных момента:

• Storage pool construct - vSAN 8 ESA, помимо концепции дисковых групп, дискретного кэширования и ярусов емкостей (capacity tiers), дает пользователям возможность объединить устройства в пул (storage pool), в котором все устройства пула хоста могут давать емкость в общую емкость инфраструктуры vSAN. Это упрощает операции по обслуживанию дисков и управлению доступностью данных (а также снижает затраты).
• Упрощенное развертывание и оперирование ресурсами хранилищ - теперь появились автоматические проверки, которые позволяют понять, что архитектура ESA запущена на поддерживаемом оборудовании. Это уменьшит количество проблемных инсталляций.

4. Ready-for-anything resilience

Этот пункт включает в себя масштабируемые и высокопроизводительные снапшоты, которые теперь делаются быстро и эффективно. Теперь снапшоты не так драматически влияют на производительность виртуальных машин, а время консолидации снапшотов уменьшилось очень значительно. Возможность native snapshot будет доступна не только в vSphere, но и для сторонних решений, использующий фреймворк VADP для резервного копирования ВМ.

Стандартная архитектура vSAN Original Storage Architecture

Классический vSAN 8 увеличил логический лимит емкости буффера почти в три раза - с 600 ГБ до 1.6 ТБ. Это позволит получит преимущества более плотного размещения виртуальных машин при сохранении требуемого уровня производительности. Рабочие нагрузки теперь могут поддерживать режим максимальной производительности в течение больших периодов времени.

Обе архитектуры vSAN - ESA и OSA

vSAN Proactive insights capability - пользователи vSAN 8 теперь получили более высокий уровень совместимости за счет функционала proactive insights, который оповещает обо всех потенциальных проблемах совместимости программного обеспечения и оборудования, даже если оно не участвует в программе Customer Experience Improvement Program. Эти улучшения доступны для обеих архитектур.

Итого прогресс технологии VMware vSAN за 10 лет можно представить вот так:

Доступность для скачивания продуктов VMware Cloud Foundation+, VMware vSphere 8, VMware vSAN 8 и VMware Edge Compute Stack 2 ожидается до 28 октября 2022 года.

Также рекомендуем посмотреть техническое видео о нововведениях vSAN:

Продолжаем рассказывать о главном продукте для создания отказоустойчивых хранилищ StarWind Virtual SAN, который позволяет обеспечивать бесперебойное функционирование кластеров виртуальных машин на базе серверов виртуализации VMware ESXi или Microsoft Hyper-V. Сегодня мы рассмотрим механизм назначения прав доступа инициаторов в консоли StarWind Management Console, с помощью которой администраторы управляют всеми аспектами виртуальных хранилищ.

В середине июня компания VMware представила сообществу Open Source свою новую разработку - нереляционную базу данных типа key-value SplinterDB. Базы данных с механиками "ключ-значение" работают очень быстро и в данный момент применяются для решения широкого круга задач. VMware сделала тут вот какую вещь - эта СУБД работает еще быстрее остальных (иногда в разы), поэтому она позиционируется как "ultra fast"-решение для высокопроизводительных нагрузок.

Платформа SplinterDB была разработана VMware Research Group в плотном сотрудничестве с группой разработки решений линейки vSAN. Ключевой особенностью этой базы данных является возможность быстро работать как с запросами на вставку/обновление данных, так и с запросами на чтение пар ключ-значение из хранилища. Вот так это выглядит в сравнении с СУБД RocksDB (она была разработана в Facebook), которая работает в той же нише, что и SplinterDB, на примере бенчмарка Yahoo Cloud Services Benchmark (YCSB):

SplinterDB максимально использует возможности ядер процессоров, легко масштабируется и использует все преимущества технологии организации хранилищ NVMe. Поэтому SplinterDB можно использовать поверх существующих key-value хранилищ, а также традиционных реляционных баз данных, NoSQL-СУБД, микросервисов, обработчиков потоков, архитектуры edge/IoT, хранилищ метаданных и графовых баз данных.

SplinterDB - это внедренное key-value хранилище во внешней памяти, что означает, что приложения используют SplinterDB путем линковки библиотеки SplinterDB в свой исполняемый файл. SplinterDB хранит данные на высокопроизводительных дисках SSD NVMe и может масштабироваться до огромных датасетов, которые значительно превышают объемы доступной памяти RAM.

На картинке выше показан пример, где SplinterDB и RocksDB хранили датасет 80 GiB в системе, имеющей 4 GiB RAM. Так как лишь малая часть базы данных помещалась в кэш оперативной памяти, то эффективность работы подсистемы ввода-вывода была ключевым фактором оценки производительности. Для теста использовались диски Intel Optane SSD, которые поддерживают 2 GiB/sec на чтение и запись. При этом RocksDB использовала только 30% доступного канала обмена с хранилищем (для операций записи), а SplinterDB использовала до 90% канала. При чтении SplinterDB также показала себя в полтора раза лучше, чем RocksDB, за счет более эффективного использования CPU и техник кэширования.

В чем же секрет такого высокого уровня производительности? Дело в том, что современные key-value хранилища (включая SplinterDB, RocksDB, LevelDB, Apache Cassandra и другие) хранят данные в больших сортируемых таблицах. Запросы ищут значения в каждой таблице, спускаясь от новых данных к старым. Таким образом, запросы замедляют систему, накапливая все больше и больше таблиц с данными. Чтобы избежать замедления работы, эти системы время от времени объединяют несколько отсортированных таблиц в одну (это называется compaction). Это и создает дисбаланс между скоростью на чтение и скоростью на запись. За счет этого запросы исполняются быстро, но вот вставка данных замедляется. Если compaction делать реже, то вставка будет работать быстрее, но и чтение замедлится.

SplinterDB делает compaction более чем в 8 раз реже, чем RocksDB, поэтому вставка данных и работает в первой примерно в 7 раз быстрее, чем во второй. Но что со скоростью на чтение? Чтобы поддерживать высокую скорость чтения, SplinterDB работает иначе, чем современные хранилища. Большинство из них используют фильтры Bloom (или их еще называют cuckoo), чтобы ускорять запросы.

Фильтр - это маленькая структура данных, которая представляет некое множество из таблицы. RocksDB и аналоги используют один фильтр для каждой таблицы, и запросы прежде всего проверяют фильтр перед тем, как искать во всей таблице, чтобы большинство запросов могли искать только в небольшой структуре. Задумка здесь в том, что фильтры будут хранится в памяти, поэтому I/O операции с хранилищами будут вызываться нечасто.

На быстрых хранилищах этот подход работает не так эффективно, особенно когда набор данных в БД значительно превышает размер доступной оперативной памяти. На быстрых хранилищах затраты на CPU при поиске в фильтрах могут быть высокими ввиду большого числа фильтров. При этом может произойти ситуация, когда фильтры не помещаются в память, поэтому они отбрасываются на диск, что делает их использование в этом случае бесполезным.

SplinterDB использует новый вид фильтра, называемый routing filter. Один такой фильтр может заменить несколько фильтров типа Bloom, cuckoo или ribbon и может покрыть сразу несколько таблиц. Обычные фильтры могут сказать только, есть ли соответствующий ключ в доступности в данный момент или нет, а вот routing filter может не только сказать, что ключ есть, но и указать на то, какая конкретно из отсортированных таблиц его содержит. Поэтому запросам нужно делать гораздо меньше работы по поиску в фильтрах, а значит снижается нагрузка на CPU.

Кроме того, поиск в одном фильтре может сильно сэкономить на запросах ко многим таблицам, даже если этот фильтр занимает много места в RAM. Этот механизм работы с данными и был придуман в VMware. Все это позволяет существенно экономить на вычислительных мощностях для очень тяжелых и интенсивных нагрузок.

Более подробно о данной технологии можно почитать на официальном сайте SplinterDB, репозиторий продукта на GitHub доступен тут.

Мы довольно часто пишем о максимальных параметрах виртуальной инфраструктуры VMware vSphere и ее компонентов, в частности VMware vCenter (например, тут и тут). Сегодня мы немного освежим эти данные на примере последней версии сервера управления vCenter и приведем несколько примеров. Для начала напомним, что актуальные данные по максимальным конфигурациям продуктов VMware можно найти по адресу: https://configmax.vmware.com, а также в официальной документации.

Кроме того, у VMware есть отличное видео, посвященное лимитам vCenter и правилам выполнения одновременных операций в виртуальной среде:

Итак, лимиты можно разделить на 2 категории:

• Глобальные лимиты для инфраструктуры (виртуальный датацентр).
• Лимиты на уровне хоста и его компонентов (например, сетевые адаптеры).

Если говорить о глобальных параметрах, то значения тут следующие:

• Вы можете запустить до 640 одновременных операций в vCenter, пока они не начнут становиться в очередь.
• Всего можно запустить до 2000 одновременных операций на один сервер vCenter.

На уровне хостов ESXi есть следующие механизмы работы и ограничения:

• Хосты ESXi 6 и 7 версий имеют 16 слотов для выполнения операций в единицу времени:

• Любая операция с виртуальными машинами потребляет какое-то количество слотов на источнике и целевом хосте.
• Операция Storage vMotion стоит 8 слотов на хост. Если вы меняете только датастор у виртуальной машины, оставляя тот же хост, то потребляются эти 8 слотов, то вы можете сделать 2 одновременных миграции. Ранее это работало несколько иначе - смотрите наш пост вот тут.
• Операция Linked clone потребляет 1 слот, но для этого у вас уже должен быть создан снапшот. Если у вас его нет, то он сначала создается - это может замедлить создание первого связанного клона. Также снапшот требуется и при клонировании включенной ВМ, где требуется уже 2 слота (то есть одновременно можно делать 8 таких операций для данной пары хостов).

• Операции Clone, Relocate и vMotion стоят 2 слота каждая на каждом хосте - то есть и на источнике, и на целевом (суммарно получается потребляется 4 слота на двух хостах). Это же работает и при клонировании ВМ на том же самом хосте - на нем в этот момент потребляется 4 слота (то есть одновременно на хосте можно делать 4 таких операции).

Для датасторов также есть слоты и ограничения на одновременные операции:

• У одного датастора есть 128 слотов.
• Операция vMotion стоит 1 слот, то есть на одном датасторе может проходить до 128 одновременных миграций vMotion.
• Операция Storage vMotion стоит 16 слотов, то есть на одном датасторе может проходить до 8 одновременных миграций vMotion.
Это же работает и для датасторов vSAN, где часто встречаются конфигурации с одним датастором - это надо иметь в виду.

Лимиты для сетевых адаптеров сейчас следующие (помните, что для vMotion лучше иметь отдельный адаптер или выделенную пару портов на нем):

• У 1Gb NIC есть 4 слота, то есть можно делать до 4 одновременных миграций vMotion через этот адаптер.
• У 10Gb и 25Gb NIC есть 8 слотов, то есть можно делать до 8 одновременных миграций vMotion через такие адаптеры.

Более подробно об организации адаптеров для vMotion вы можете прочитать в KB 2108824.

Многие из вас используют или интересуются решением StarWind Virtual SAN, которое является сейчас одним из основных продуктов на рынке для организации отказоустойчивых кластеров хранилищ (а еще и самым технологически продвинутым). Сегодня мы поговорим об узле Witness node в кластерах и о том, как он помогает защитить его от массовых сбоев в виртуальной среде.

Одним из нововведений новой версии решения для обеспечения катастрофоустойчивости виртуальной инфраструктуры хранения VMware vSAN 7.0 Update 3 стал улучшенный механизм по обработке последовательных отказов. Называется он Enhanced Data Durability.

Он позволяет еще больше защитить кластер хранилищ от аварий и сбоев, которые могут происходить не в один момент, а друг за другом на протяжении некоторого времени.

Нужен он для того, чтобы в ситуации, когда отказывает одна из площадок vSAN, а потом и компонент Witness (например, в случае массового сбоя сети или аварии другой природы), хосты выжившего кластера могли продолжить работу.

Проиллюстрируем это на примере, который привел Дункан Эппинг. Предположим, у нас есть вот такая инфраструктура:

И вот у нас отказывает полностью один из датацентров. В консоли RVC мы увидим следующее:

  VM R1-R1:

  Disk backing:

  [vsanDatastore] 0b013262-0c30-a8c4-a043-005056968de9/R1-R1.vmx

  RAID_1

  RAID_1

  Component: 0b013262-c2da-84c5-1eee-005056968de9 , host: 10.202.25.221

  votes: 1, usage: 0.1 GB, proxy component: false)

  Component: 0b013262-3acf-88c5-a7ff-005056968de9 , host: 10.202.25.201

  votes: 1, usage: 0.1 GB, proxy component: false)

  RAID_1

  Component: 0b013262-a687-8bc5-7d63-005056968de9 , host: 10.202.25.238

  votes: 1, usage: 0.1 GB, proxy component: true)

  Component: 0b013262-3cef-8dc5-9cc1-005056968de9 , host: 10.202.25.236

  votes: 1, usage: 0.1 GB, proxy component: true)

  Witness: 0b013262-4aa2-90c5-9504-005056968de9 , host: 10.202.25.231

  votes: 3, usage: 0.0 GB, proxy component: false)

  Witness: 47123362-c8ae-5aa4-dd53-005056962c93 , host: 10.202.25.214

  votes: 1, usage: 0.0 GB, proxy component: false)

  Witness: 0b013262-5616-95c5-8b52-005056968de9 , host: 10.202.25.228

  votes: 1, usage: 0.0 GB, proxy component: false)

Здесь мы видим, что у нас 1 голос на каждый из дисковых компонентов основной площадки (итого 2), 3 голоса на Witness и 2 голоса на резервной площадке.

Теперь представим, что все хосты резервной площадки отказывают полностью. У нас остается 2+3=5 голосов из 7, то есть кворум есть, все в порядке (для обеспечения кворума нужно больше 50% голосов). Но вот если у нас после этого откажет компонент Witness, имеющий 3 голоса, то у нас останется только 2 голоса из 7, кворума не будет - и это может привести к проблемам в кластере.

Для этого в vSAN 7 Update 3 сделали механизм пересчета голосов. Посмотрим на то, как выглядит картина через 5 минут после отказа резервной площадки в консоли RVC:

  VM R1-R1:

  Disk backing:

  [vsanDatastore] 0b013262-0c30-a8c4-a043-005056968de9/R1-R1.vmx

  RAID_1

  RAID_1

  Component: 0b013262-c2da-84c5-1eee-005056968de9 , host: 10.202.25.221

  votes: 3, usage: 0.1 GB, proxy component: false)

  Component: 0b013262-3acf-88c5-a7ff-005056968de9 , host: 10.202.25.201

  votes: 3, usage: 0.1 GB, proxy component: false)

  RAID_1

  Component: 0b013262-a687-8bc5-7d63-005056968de9 , host: 10.202.25.238

  votes: 1, usage: 0.1 GB, proxy component: false)

  Component: 0b013262-3cef-8dc5-9cc1-005056968de9 , host: 10.202.25.236

  votes: 1, usage: 0.1 GB, proxy component: false)

  Witness: 0b013262-4aa2-90c5-9504-005056968de9 , host: 10.202.25.231

  votes: 1, usage: 0.0 GB, proxy component: false)

  Witness: 47123362-c8ae-5aa4-dd53-005056962c93 , host: 10.202.25.214

  votes: 3, usage: 0.0 GB, proxy component: false)
 

Итак, мы видим, что каждый из дисковых компонентов получил по 3 голоса. Компонент Witness вне площадок получил 1 голос вместо 3, а компонент Witness, поднявшийся на основной площадке также получил 3 голоса.

Теперь, если внешний компонент Witness упадет, то кворум кластера все равно будет соблюден, а машины продолжат исполняться на основной площадке. Если же резервная площадка снова войдет в строй, то голоса в кластере снова будут пересчитаны таким образом, чтобы соблюсти статус кво.

Как долго происходит пересчет голосов в кластере? Это зависит от количества дисковых объектов, голоса которых учитываются. В среднем на одну ВМ приходится по несколько секунд вычислений, поэтому общая реконфигурация состава голосов может занять до 5 минут. Зато в этом случае кластер будет более устойчив к отказам, которые в реальной жизни могут происходить один за другим.

Многие из вас знают компанию StarWind Software, лидера в сфере поставки программных и программно-аппаратных решений для создания отказоустойчивых хранилищ. Помимо решений непосредственно для организации хранилищ, у компании есть и виртуальный модуль StarWind Backup Appliance, который предназначен для резервного копирования виртуальных машин на хранилищах StarWind. Это программно-аппаратный комплекс на базе оборудования NVMe, который позволяет избавиться от проблемы производительности хранилищ резервных копий и забыть о задаче планирования окна резервного копирования.

Модуль StarWind Backup Appliance поставляется в виде настроенного и готового к работе сервера резервного копирования, построенного на базе StarWind HyperConverged Appliance (HCA). Работа с продуктом происходит через удобный веб-интерфейс StraWind Web UI, есть также плагин StarWind для vCenter.

В апреле компания StarWind объявила, что StarWind Backup Appliance теперь включает в себя оборудование GRAID SupremeRAID - первую в мире карточку NVMe-oF RAID, которая обеспечивает высочайший уровень защиты данных в рамках технологии NVMe RAID на рынке.

Традиционные RAID-контроллеры не были разработаны изначально для технологии NVMe, а программные RAID работают недостаточно эффективно, потребляя при этом большое число циклов CPU, что мешает рабочим нагрузкам сервера. Поэтому с теперь помощью карточек GRAID комплексы StarWind Backup Appliance обеспечат максимальную производительность и защиту данных на базе дисков NVMe SSD.

Вот так выглядят результаты тестов технологии GRAID по сравнению с текущими реализациями аппаратных RAID для NVMe:

Более подробно об этом нововведении можно узнать из пресс-релиза StarWind. Скачать пробную версию StarWind Backup Appliance можно по этой ссылке.

На днях компания VMware анонсировала новое решение Cloud Flex Storage, которое представляет собой распределенное хранилище и средства управления данными, полностью управляемые со стороны VMware. Это комбинация cloud-native абстракций, реализующих службы хранения для клиентов, которая предоставляет высокопроизводительные сервисы для современных нагрузок.

С помощью VMware Cloud Services Console пользователи могут масштабировать облачные хранилища без необходимости добавления дополнительных хостов и регулировать доступные емкости как вверх, так и вниз, для каждого из работающих приложений. Также здесь работает модель оплаты по мере потребления ресурсов (pay-as-you-go).

Решение VMware Cloud Flex Storage построено на базе файловой системы enterprise-класса, которая разрабатывается уже много лет на базе продукта Datrium D­HCI, купленного VMware в июле 2020 года. Эта же файловая система используется для сервиса VMware Cloud Disaster Recovery. Она имеет двухъярусный дизайн, который позволяет просто масштабировать емкость и производительность хранилищ, используя архитектуру Log-Structured Filesystem (LFS).

Там доступны такие возможности, как эффективные снапшоты, неизменяемость бэкапов (immutability), защита от ransomware и многое другое, что позволяет использовать их для разных типов организаций и рабочих нагрузок.

Вот основные варианты использования VMware Cloud Flex Storage:

• Бесшовная миграция данных в облако при сохранении разумных затрат. Для пользователей, которые используют VMware Cloud on AWS, сервисы Cloud Flex Storage реализуют высокопроизводительные хранилища, способные выдерживать большие всплески нагрузки. Виртуальные машины можно перемещать между ярусами, а также без ручных операций обеспечивать требуемый уровень производительности в автоматическом режиме.
• Эластичное расширение хранилищ датацентров. Пользователи VMware Cloud on AWS могут дополнительно подключать ресурсы Cloud Flex Storage для получения дополнительных емкостей. Это позволяет на лету масштабировать хранилища вверх и вниз, перемещать нагрузки в те датацентры, которые наиболее эффективно работают с актуальными данными в публичном облаке. Также все это дает возможности по управлению гибридной инфраструктурой организаций из единой консоли VMware vCenter.
• Масштабирование нагрузок для высокоинтенсивных в плане хранилищ приложений. Если VMware Cloud on AWS используют локальные инстансы на базе VMware vSAN, но их мощностей не хватает, Cloud Flex Storage может быстро дать распределенные облачные хранилища на базе потребностей каждого конкретного приложения. Также эта архитектура хорошо подходит для масштабирования больших томов данных.

Сейчас решение Cloud Flex Storage полностью сфокусировано на пользователях публичного облака VMware Cloud on AWS и имеет глубокую интеграцию со службами vSAN.

Пока VMware только приглашает пользователей в программу раннего доступа к Cloud Flex Storage, который можно получить, обратившись по этому адресу.

Компания VMware объявила о выпуске обновления решения Object Storage Extension 2.1.1, которое уже доступно для скачивания на портале VMware Customer Connect. Напомним, что это фремворк для поддержки хранилищ S3 в инфраструктуре сервис-провайдеров, которые работают на базе VMware Cloud Director. Напомним, что о версии OSE 2.1 мы писали осенью прошлого года вот тут.

Давайте посмотрим, что нового в Object Storage Extension 2.1.1:

1. Поддержка новых ОС

OSE 2.1.1 теперь поддерживает большой спектр дистрибутивов Linux, среди которых такие системы, как Photon OS 3+, Ubuntu 18+ и Debian 10+.

2. Функции Object Lock и тэгирование объектов для пользователей Dell ECS 3.6

Клиенты в облаке под управлением VMware Cloud Director могут быть отображены в сущности ECS Identity и Account Access Management (IAM) вместо того, чтобы оставаться пользователями объектов ECS. Это позволяет независимо управлять функциональностью object lock и тэгированием. Напомним, что object lock - это функция предотвращения перезаписи или удаления объектов на фиксированное время, которая может быть активирована при создании бакета. А тэгирование позволяет категоризировать бакеты путем назначения тэгов отдельным объектам с использованием пары ключ-значение.

Маппинг пользователей можно получить после простого апгрейда на cloud provider portal, но это остается опциональным.

3. Дополнительная поддержка

В прошлом релизе VMware выпустила службы Object Storage Interoperability Services (OSIS), позволюящие интегрировать любые сторонние S3-compliant объектные хранилища с VMware Cloud Director, которые управляются через REST API. Теперь функции служб совместимости были существенно доработаны, и облачные провайдеры могут использовать OSIS stub, OSIS verifier и Common Test Suites для определения совместимости и готовности компонентов для имплементации OSIS.

4. Исправления ошибок

Было сделано множество небольших улучшений и исправлений ошибок, полный список которых приведен в release notes.

Для обновления инфраструктуры на Object Storage Extension 2.1.1 облачные провайдеры могут использовать страницу upgrade guide.

Продолжаем рассказывать технические подробности о работе продукта StarWind Virtual SAN, позволяющего создавать программные и программно-аппаратные отказоустойчивые кластеры iSCSI для виртуальных сред. Сегодня мы поговорим о расширенных настройках протокола iSCSI на стороне StarWind и на стороне VMware ESXi, чтобы обеспечить непрерывное функционирование приложений в виртуальных машинах при обрыве соединений.

Стек работы с хранилищами VMware ESXi настроен таким образом, чтобы адекватно реагировать на кратковременную потерю сигнала в канале iSCSI, которая может возникнуть по разным причинам (кто-то перекоммутировал соединение, дрогнул порт и т.п.). По умолчанию расширенные настройки iSCSI выставлены так, чтобы переживать кратковременные сбои в рамках одного пути в интервале 25-35 секунд. В это время I/O-запросы будут копиться в очереди, а потом, либо произойдет продолжение передачи при восстановлении текущего соединения, либо хост переключится на резервный путь (failover) текущего или резервного адаптера.

В то время, как такое поведение не является критичным для большинства приложений, иногда есть специфические требования, которые надо выполнять для отдельных систем. Например, если речь идет о системе видеонаблюдения, то там задержка в полминуты является неприемлемой, и ее надо обрабатывать быстрее.

Для этого, если вы используете хранилища StarWind Virtual SAN, есть специальные настройки реагирования на подобные ситуации.

Итак, для начала вам нужно остановить службы StarWind Virtual SAN:

• В консоли StarWind Management Console проверить, что все устройства StarWind HA находятся в статусе "Synchronized" на всех серверах
• Проверить, что все датасторы имеют активные задублированные пути для всех серверов StarWind, а политика доступа по нескольким путям (MPIO) установлена в Round Robin
• На StarWind VSAN для Windows нужно выполнить команду для остановки служб StarWind: net stop starwindservice
• На виртуальном модуле StarWind VSA нужно выполнить такую команду: systemctl stop StarWindVSA

Далее открываем конфигурационный файл:

• На StarWind VSAN для Windows: C:\Program Files\StarWind Software\StarWind\StarWind.cfg
• На виртуальном модуле StarWind VSA: nano /opt/StarWind/StarWindVSA/drive_c/StarWind/StarWind.cfg

Далее там находим параметр iScsiPingCmdSendCmdTimeoutInSec и выставляем его значение, например в "1" (одна секунда).

Ну и, наконец, надо запустить службы StarWind VSAN:

• На StarWind VSAN для Windows: net start starwindservice
• На виртуальном модуле StarWind VSA: systemctl start StarWindVSA

Теперь нужно добраться до расширенных настроек iSCSI инициатора VMware ESXi. Открываем Advanced Options для адаптера в разделе Storage Adapters нужного нам инициатора:

И смотрим, какие настройки там выставлены:

Нас интересует:

• RecoveryTimeout - это как раз время, через которое активный путь помечается как "мертвый" (переводится в DEAD_STATE), когда по нему больше не приходит команд ввода-вывода.
• NoopInterval - это интервал, с которым происходит пассивное тестирование неактивных путей на предмет того, живы ли они.
• NoopTimeout - это время, через которое происходит пометка неактивного пути как DEAD, если по нему не получено ответа.

Эти настройки по умолчанию установлены в оптимальные с точки зрения вероятности отказа/потерь значения. Меняйте их только, если у вас есть особые требования приложений по непрерывной доступности хранилищ, и вы знаете, какое поведение системы хотите получить. Уменьшение таймаутов, очевидно, ведет к загрузке сети пингами каналов iSCSI и дополнительной нагрузке на устройства.

Это статьей мы начинаем цикл публикаций и продукте NAKIVO Backup & Replication в контексте отдельных его функций. Напомним, что он предназначен для резервного копирования и репликации виртуальных машин в инфраструктуре VMware vSphere и Microsoft Hyper-V. Вводную статью об основных возможностях этого решения вы можете прочитать вот тут, а сегодня мы подробно расскажем о его механизмах по резервному копированию данных сервисов Microsoft Office 365.

Дункан написал хорошую разъясняющую статью про загрузку ESXi с SD-карты и размещение раздела OSDATA на хранилище в SAN. Напомним, что мы писали о том, что VMware уходит от механизма загрузки ESXi с SD-карт ввиду их низкой надежности и неприспособленности под задачи гипервизора.

Как знают администраторы VMware vSphere, начиная с седьмой версии платформы, структура разделов ESXi теперь выглядит следующим образом:

Как мы видим, все основные разделы, не относящиеся к загрузке переехали в раздел ESX-OSDATA. Многие администраторы хотели бы хранить загрузочный раздел локально на SD-карте, а OSDATA - в сети SAN.

К сожалению, это не поддерживается.

Давайте взглянем на таблицу допустимых конфигураций из вот этой статьи VMware:

Действительно, тут как бы есть пункт, что при загрузке ESXi можно использовать SD-карту для Bootbank, а Managed FCoE/iSCSI LUN для OSDATA (но обратите внимание, что это Locally attached devices). Реально же FCoE, iSCSI и FC для загрузки ESXi с SAN можно использовать только тогда, когда и OSDATA, и Bootbank находятся на SAN-устройстве.

Продолжаем рассказывать вам о продуктах компании StarWind, которая является одним из лидеров в сфере производства программных и программно-аппаратных хранилищ виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V. Сегодня мы расскажем о бесплатной утилите V2V Converter / P2V Migrator, которая позволяет делать три важных для администратора вещи...

Аналитическая компания Gartner выпустила отчет "2021 Magic Quadrant for Hyperconverged Infrastructure Software", отражающий ситуацию на рынке гиперконвергентной инфраструктуры. Это такая инфраструктура, где все ее вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.

Компания VMware заняла в этом квадранте место лидера (надо отметить, что учитывались не только онпремизные, но и облачные HCI-инициативы), расположившись рядом со своим главным конкурентом в этой сфере - компанией Nutanix:

Может показаться, что многие вендоры гиперконвергентных решений просто сошли с дистанции за пару лет. Давайте взглянем на тот же квадрант за 2018 год, где были решения от HPE, Dell EMC и Cisco:

Но дело совсем не в этом, просто поменялась методика определения игроков - теперь в квадрант добавляют только тех вендоров, которые предоставляют интегрированное решение для гиперконвергентной инфраструктуры на базе серверов, а значит оттуда убрали Cisco, Dell EMC, HPE, Huawei и Red Hat. Более подробно об этом вы можете почитать здесь.

VMware занимает место в квадрате лидеров заслуженно, несмотря на то, что не занимается производством аппаратного обеспечения. Очевидно, что в гиперконвергентной среде сложно построить инфраструктуру на базе одного вендора, поэтому в любом случае нужны решения для виртуализации и агрегации ресурсов.

Приятно также видеть среди ведущих HCI-производителей компанию StarWind Software, флагманским продуктом которой в HCI-сфере является программно-аппаратное решение StarWind HyperConverged Appliance (HCA), о котором мы писали вот тут.

Скачать отчет 2021 Magic Quadrant for Hyperconverged Infrastructure Software можно по этой ссылке.

В начале осени, в рамках прошедшей конференции VMworld 2021 Online, компания VMware представила свое виденье развития концепции виртуализации и агрегации хранилищ корпоративных инфраструктур - Federated Storage Platform (FSP).

Проблема современного подхода к организации хранилищ состоит в том, что аппаратные комплексы в датацентре представлены разными моделями, производителями, а также поколениями в рамках одной продуктовой линейки. Ввиду этого администраторам приходится разрабатывать набор административных регламентов по обслуживанию жизненного цикла таких хранилищ - ввод в эксплуатацию, развертывание новых сервисов, обеспечение высокой доступности и план по изменению емкостей - вывод устаревших систем и расширение существующих емкостей. Ко всему этому добавляются Day-2 Operations и обеспечение безопасности хранения данных виртуальных и физических сред.

Как итог - корпоративная инфраструктура предприятия не может обеспечить те же преимущества, что и унифицированная облачная среда, которая избавляет администраторов от заботы об оборудовании и, в частности, хранилищах.

Проблему отчасти решает подход к организации гиперконвергентной инфраструктуры (Hyperconverged Infrastructure, HCI), например, концепция HCI Mesh. Но этого было недостаточно, и VMware запустила радикальную инициативу - Federated Storage Platform (FSP) - решение, которое приведет к унификации операций онпремизных и облачных сред в плане хранилищ за счет их виртуализации и агрегации.

С помощью VMware FSP можно будет управлять любым числом хранилищ разных вендоров, с которыми работает любое количество управляющих серверов vCenter:

Здесь будет 2 ключевых сущности:

• Common volumes - это новый слой представления ресурсов хранения от гетерогенных кластеров vSAN, томов vSphere Virtual Volumes дисковых массивов, а также NFS-массивов. Все это будет объединено на уровне пулов.
• Data center control plane - новый слой управления инфраструктурой хранения на базе эластичных пулов с возможностью полного доступа к имеющимся емкостям. Все это позволит видеть ресурсы хранения как в облаке, безотносительно имеющихся моделей массивов и топологий.

FSP будет полностью интегрирован в уже имеющимся механизмом политик хранения SPBM (vSphere Storage Policy Based Management), предоставляя гибкие пулы хранения для уровня приложений на базе их потребностей. Платформа VMware vSphere будет выступать как один из потребителей ресурсов в рамках этой концепции.

Для обеспечения различных уровней сервиса будут работать расширенные политики FSP, такие как квоты на емкости и ограничения по производительности, чтобы обеспечить ярусность хранения и работы с данными.

В рамках FSP процесс добавления или списания хранилищ будет бесшовным, то есть не вовлекать физическую коммутацию, которая будет выводиться за рамки процесса управления единым пулом хранилищ. Например, FSP может автоматически обнаружить новое уже подключенное хранилище, после чего добавить его в общий federated пул и начать балансировку нагрузок посредством VMware vSphere Storage vMotion.

Сейчас администраторам приходится вручную выполнять операции SVMotion для ввода новых хранилищ в эксплуатацию и их вывода, а FSP будет делать все это автоматически в "lazy"-режиме, чтобы обеспечивать уровень производительности виртуальной среды.

FSP будет интегрирована с драйвером vSphere CSI в Kubernetes, а также технологией CNS (Cloud Native Storage). Разработчики смогут потреблять дисковые емкости в рамках классов через FSP, а администраторы получать полную видимость использования таких хранилищ на уровне всего датацентра.

Сейчас решения VMware vSphere with VMware Tanzu и TKG-S VMware Tanzu Kubernetes Grid могут развертывать рабочие нагрузки в рамках пространств имен кластера, а FSP даст возможность развернуть приложения на любом хранилище в любом кластере на базе любых доступных политик.

Сейчас с помощью x-vMotion виртуальную машину можно перемещать между кластерами и разными инфраструктурами vSphere. FSP расширит эти возможности, позволяя виртуальным машинам и контейнеризованным приложениям свободно "путешествовать" между кластерами, инфраструктурами и пространствами хранения - при этом под полным контролем управляющего слоя.

Получить больше информации об инициативе можно из записи этой ссессии с прошедшего VMworld 2021 Online: VMware’s vision for storage and data in a multi-cloud world.

Этой осенью мы писали о новых возможностях флагманской платформы виртуализации компании VMware - vSphere 7 Update 3 и Update 3a. При этом мы забыли рассказать о новой версии платформы для создания отказоустойчивых хранилищ VMware vSAN 7 Update 3. Сегодня мы закроем этот пробел.

Итак, вот какие новые возможности были добавлены в VMware vSAN 7 Update 3:

1. Cluster Shutdown

Эта функция позволяет вам погасить все хосты кластера для проведения обслуживания, даже в том случае, если они исполняют серверы vCenter. Для начала процедуры выключения хостов нужно выбрать пункт "shutdown cluster" из контекстного меню кластера и запустить двухшаговый мастер.

На первом этапе пройдут предпроверки, которые убеждаются в том, что в данный момент нет активных задач ресинхронизации, отсутствуют хосты в режиме обслуживания, служебные ВМ выключены и другое:

2. Поддержка vLCM для виртуального модуля Witness Appliance

Теперь жизненной цикл виртуальной машины Witness Appliance в кластере можно обслуживать с помощью vSphere Lifecycle Manager (делать апгрейд и прочее).

3. Функции Skyline Health Correlation

С помощью возможности Skyline Health Correlation пользователи, которые видят множество срабатывающих в кластере алармов, понимают, что им нужно сделать. В vSAN 7 U3 можно понять корреляцию между событиями и сделать вывод о наиболее вероятной проблеме. Далее уже можно приступать к поиску корневой причины.

4. Возможность IO Trip Analyzer

IO Trip Analyzer - это средства, которые позволяют посмотреть информацию о задержках (latency) на каждом из уровней в форме диаграммы. Вот небольшой обзор этого инструмента от Дункана Эппинга:

5. Вложенные домены отказа Nested Fault Domains для 2-узловых кластеров

Домены Nested Fault Domains для 2-узловых кластеров предназначены для пользователей, которые хотят получить устойчивую к отказам конфигурацию на базе всего двух хостов ESXi. Для этого нужно иметь как минимум 3 дисковых группы на хост на каждом из узлов, после чего создается массив RAID-1 между этими двумя хостами, а также RAID-1 внутри каждого из хостов (можно также использовать RAID-5, если у вас достаточное количество дисковых групп). Если упадет один из хостов ESXi, а потом и еще один из дисков на выжившем хосте - то виртуальные машины все равно продолжат работать.

6. Функции Enhanced Stretched Cluster Durability

Мы уже писали о возможностях Enhanced Data Durability для кластеров vSAN, позволяющих еще больше защитить кластер хранилищ от аварий и сбоев, которые могут происходить не в один момент, а друг за другом на протяжении некоторого времени.

Теперь функции Enhanced Stretched Cluster Durability позволяют обработать ситуацию, когда отказывает одна из площадок растянутого кластера, а после этого и компонент Witness сторонней площадки. В этом случае ВМ растянутого кластера ранее оказывались недоступны, потому что последовательно происходил отказ двух из трех компонентов RAID растянутого кластера. В случае одновременного отказа сайта и компонента Witness происходила блокировка второго сайта и для обеспечения консистентности данных и защиты от ситуации Split Brain. Теперь же происходит обработка и ситуации последовательного отказа сайта и Witness.

В этом случае обеспечивается строгая консистентность данных виртуальных машин, так как упавший сайт может лежать достаточно долго.

Если все дисковые объекты виртуальных машин сохранились на работающей площадке, то даже в случае недоступности Witness все виртуальные машины продолжат свою нормальную работу. Более подробно об этой возможности Дункан рассказал вот тут.

7. Механизм Access Based Enumeration для SMB-шар через службы vSAN File Services

До vSAN Update 3, если пользователь имел доступ к SMB-шаре, то он мог просматривать список всех ее каталогов. Теперь же с помощью Access Based Enumeration для служб vSAN File Services пользователь видит только назначенные ему папки.

Посмотреть полный список новых возможностей VMware vSAN 7 Update 3 можно в Release Notes, а загрузить продукт можно по этой ссылке.

Также в комментариях поделились полезным видео от русской команды VMware, где рассказывается не только о новых возможностях vSAN 7 Update 3, но и о нововведениях vSphere и Tanzu в новом апдейте:

Многим из вас знакомы продукты компании StarWind, предназначенные для создания отказоустойчивых хранилищ под различные платформы виртуализации. Сегодня мы поговорим о том, как настраивать аутентификацию доступа к хранилищам через протокол CHAP в решении StarWind Virtual SAN...

Вчера мы писали о новых возможностях анонсированного недавно обновления платформы виртуализации VMware vSphere 7 Update 3. Сегодня мы чуть детальнее разберем возможности обновленного продукта, касающиеся хранилищ виртуальных машин. Нововведения были сделаны в следующих областях:

1.Поддержка NVMe over TCP

В релизе vSphere 7.0 была анонсирована поддержка технология NVMe over Fabrics, где первоначально поддерживались только протоколы FC и RDMA. Теперь же поскольку SSD-хранилища продолжают набирать популярность, а транспорт Non-Volatile Memory Express (NVMe) стал стандартом для многих типов систем, в vSphere 7 Update 3 появилась поддержка и NVMe over TCP, которая позволяет использовать стандартную инфраструктуру TCP/IP, оптимизированную под Flash и SSD, для трафика хранилищ. Это поможет в некоторых случаях существенно сэкономить на оборудовании.

2. Увеличение числа хостов на один датастор

У VMware есть какое-то количество клиентов, которые достигли предыдущего лимита в 64 хоста ESXi на одно виртуальное хранилище VMFS или NFS. В Update 3 этот лимит был расширен до 128 хостов. Надо понимать, что к лимитам кластера это число не имеет отношения - это только число хостов, которые могут одновременно использовать датастор.

3. Affinity 3.0 и поддержка CNS

В vSphere 7 компания VMware обновила Affinity Manager до версии 2.0, который уменьшает затраты на первые операции записи для thin и lazy thick дисков. В Affinity 3.0, который вошел в этот релиз, появилась поддержка персистентных томов Cloud Native Storage (CNS), которые также называются FCD (First Class Disks). Также добавлена поддержка большего числа хостов ESXi на один кластер.

4. Пакетные снапшоты томов vVols

В этом обновлении vSphere была существенно улучшена процедура обработки большого одновременного количества снапшотов томов vVol, которая может происходит в рамках процессов обслуживания хранилищ и резервного копирования. Операции снапшотов группируются и обрабатываются в рамках пакетного процесса, уменьшается общее число операций, поэтому в итоге нагрузка на хранилища уменьшается.

Более подробно обо всех новых возможностях VMware vSphere 7 Update 3 в отношении хранилищ рассказано в этой статье.

На днях компания VMware объявила о релизе новой версии решения Object Storage Extension 2.1 (OSE). Напомним, что это фремворк для поддержки хранилищ S3 в инфраструктуре сервис-провайдеров, которые работают на базе VMware Cloud Director. Год назад мы упоминали о выпуске версии 2.0, а сегодня расскажем, что нового там появилось за это время.

Итак, новые возможности Object Storage Extension 2.1:

1. Резервное копирование и восстановление по запросу для Kubernetes (оно же K8s B&R)

VMware Cloud Director Object Storage Extension теперь имеет встроенные возможности Kubernetes Backup & Restore (K8s B&R), которые доступны непосредственно в VMware Cloud Director. Теперь облачные провайдеры могут защищать не только виртуальные машины, но и рабочие нагрузки контейнеризованных приложений. Возможности K8s B&R построены на базе решения Velero, которое использует S3-протокол для хранения резервных копий, чтобы защитить данные на персистентных томах.

Резервное копирование изначально поддерживает инфраструктуру большого количества клиентов (multi-tenancy), которые работают с кластерами TKG, CSE-кластерами и отдельными K8s-инсталляциями под управлением Container Service Extension 3.0. Также при бэкапе используется end-to-end шифрование.

Подробнее о новых функциях резервного копирования рассказано тут.

2. Доступ к облачным политикам хранения Cloudian

Политики объектных хранилищ Cloudian позволяют обеспечивать защиту и распределение хранилищ между потребителями в рамках организации. С помощью простых правил облачные провайдеры могу дать пользователям возможности создавать свои бакеты и объекты. Начиная с версии OSE 2.1, клиенты, которые используют Cloudian, могут создавать кастомные политики хранилищ непосредственно из OSE. Более подробно об этом написано тут.

3. Улучшенная синхронизация бакетов и вывод объектов

Для клиентов с несколькими площадками бакеты теперь агрегируются в рамках одного представления в консоли VMware Cloud Director. Облачные провайдеры могут наблюдать за статусом синхронизации бакетов своих клиентов. Также на глобальном уровне доступна опция синхронизации бакетов, которую могут включить администраторы сервис-провайдера, чтобы убедиться, что все мультисайтовые бакеты синхронизированы (включение этой фичи можно также поставить в планировщик). Более подробно об этом тут.

4. AWS S3 Archived Object Restoration

Amazon S3 требует, чтобы каждый объект был ассоциирован с классом хранилищ в зависимости от варианта использования. Из доступных четырех классов пользователи и администраторы облачных провайдеров могли получать доступ к Standard и Intelligent классам. Теперь же клиенты могут получить доступ к классам Glacier и Glacier Deep (но сначала нужно включить функцию restore для объектов). Более подробно VMware рассказала об этом здесь.

5. Управление на базе ролей (Role-based Access Control, RBAC)

Теперь можно использовать кастомные роли, чтобы назначить их пользователям клиентов для управления объектами vApps, Catalogs и Kubernetes B&R. В новой версии есть встроенный список удобного выбора пользовательских прав, с помощью которого администраторы облачных провайдеров (или администраторы клиентов) могут просто ограничить возможности отдельных пользователей. Детально об этом написано тут.

6. Улучшенные функции управления для ресурсов VMware Cloud Director - vApps, VM, Catalogs

В прошлой версии OSE администраторы имели ограниченную видимость при импорте и экспорте истории vApp. Теперь же вся история доступна в виде полного списка происходивших событий. Также в интерфейсе произошло несколько изменений - новое меню для создания и восстановления виртуальных приложений vApp теперь бесшовно интегрировано в консоль Cloud Director. Подробнее об этом можно почитать по этой ссылке.

Скачать VMware Object Storage Extension 2.1 можно вот тут. Есть также несколько интересных документов и материалов по продукту:

• Release Notes
• Upgrading to VMware Cloud Director Object Storage Extension 2.1
• OSE 2.1 Solution Overview
• OSE 2.1 Reference Design Whitepaper
• OSIS Development Guide

Многие администраторы VMware vSphere в крупных компаниях рано или поздно сталкиваются с необходимостью создания кластеров из виртуальных машин, например, для использования технологии высокой доступности баз данных Oracle Real Application Clusters (RAC) или для создания систем непрерывной доступности на базе технологии VMware Fault Tolerance. При использовании кластерных решений необходимо, чтобы диски ВМ находились в режиме multi-writer, то есть позволяли...

Весной этого года мы рассказывали о новых возможностях продукта VMware Cloud Disaster Recovery, который позволяет производить кросс-облачное восстановление виртуальных сред. Одним из самых страшных DR-сценариев для администраторов является поражение инфраструктуры программой-вымогателем (ransomware), которая зачастую блокирует компьютеры, а данные их дисков зашифровывает.

Традиционная инфраструктура бэкапа в этом случае может оказаться малоэффективной - ведь сложно определить момент, когда произошло инфицирование компьютеров/виртуальных машин, а также трудно быстро поднять десятки и сотни систем, ну и тяжело запустить там все процедуры проверки.

Вот какие моменты важны при борьбе с массовой атакой посредством ransomware:

• Возможность иметь достаточное количество копий назад во времени, чтобы выбрать точку чистой от вредоносного ПО системы.
• Возможность мгновенно включить ВМ для проверки, не запуская длительный процесс восстановления. Потому что таких виртуальных машин может быть очень много.
• Обеспечение сохранности и неизменности самих бэкапов - надо сделать так, чтобы зараженные машины не зашифровали сами резервные копии - ведь тогда нечего будет и восстанавливать.
• Нужно регулярно убеждаться, что бэкапы не повреждены (например, вследствие какого-то бага).
• Ну и все процедуры по восстановлению не должны стоить космических денег, что может разорить компанию.

В ответ на эти требования компания VMware разработала облачную файловую систему Scale-out Cloud Filesystem (SCFS), которая позволяет хранить готовые к восстановлению резервные копии ВМ, избегая больших затрат.

Делается это за счет комбинации в одном хранилище двухъярусной архитектуры - для хранения резервных копий и для исполнения нагрузок. Облако EC2 с локальными NVMe-хранилищами используется для обеспечения работы высокопроизводительных нагрузок (cache-tier), а S3-хранилища используются для больших объемов данных (capacity tier).

Это позволяет независимо масштабировать ресурсы для увеличения производительности и емкости. Часть cache-яруса используется для обработки входящих данных по резервному копированию, чтобы обеспечить баланс потока резервного копирования (backup-mode) и исполнения нагрузок. Когда нужно приступить к восстановлению (recovery-mode) ярус кэша может быть расширен, чтобы виртуальные машины запускались напрямую с этой файловой системы. То есть, такой дизайн файловой системы позволяет быстро переключаться между режимами backup-mode и recovery-mode.

Этот подход основан на Log-Structured Filesystem (LFS), файловой системы, которая была предложена еще в 1992 году одним из основателей VMware Менделем Розенблюмом. Она основывается на идее, что устройства хранения (HDD, SSD, S3) не так производительны в случайных операциях, как в последовательных, а sequential writes как раз удобно использовать для такой структуры хранения бэкапов. Идея LFS в том, чтобы сохранять данные изменений файловой системы в виде лога, а позже проводить его очистку.

Эти же техники использует VMware Cloud Disaster Recovery в облаке S3. Как видно из картинки, все входящие данные бэкапов разбиваются на большие сегменты в 10 МБ, которые последовательно записываются на хранилище как объекты S3 на высокой скорости. Данные хранятся в виде лога, то есть не перезаписывают прошлые данные. Это позволяет избежать ситуации, когда резервные копии виртуальных машин перезаписываются уже инфицированными бэкапами.

Для такой структуры необходим эффективный механизм по работе с указателями на данные, чтобы быстро позиционироваться на нужных блоках при запуске ВМ напрямую из резервной копии. Для этого VMware использует криптохэши на базе контента, которые невозможно подменить со стороны вредоносного ПО. Эти криптохэши организованы по структуре дерева (см. подробнее тут), а сами бэкапы недоступны для модификации из внешнего мира, то есть самой производственной среды.

При восстановлении сами бэкапы тоже не трогаются - создается копия объектов бэкапа и виртуальная машина сразу же запускается с использованием этих данных. Работает это практически мгновенно, причем неважно сколько машин запускается в рамках задачи.

Также в SCFS есть встроенный механизм проверки целостности резервных копий на ежедневной основе, что позволяет избежать ситуации, когда нужно восстанавливать системы, а данные повреждены.

Начать изучение платформы VMware Cloud Disaster Recovery можно с этой странички.

Дункан Эппинг написал интересную заметку о том, как работают Storage Rules для политик хранения виртуальных машин в кластерах VMware vSAN (VM Storage Policies).

В большой инфраструктуре или, например, в топологии HCI Mesh часто встречается такая ситуация, когда некоторые кластеры построены на базе гибридных хостов (SSD+HDD), а некоторые на базе All-Flash оборудования. Также в зависимости от типа железа, эти кластеры могут предоставлять различные сервисы (например, шифрование или дудпликацию), которые могут использовать виртуальные машины.

Когда вы создаете VM Storage Policy в решении VMware vSAN, то, начиная с vSAN 7.0 U2, вы можете задать Storage Rules для данной политики на отдельной вкладке:

Эти настройки влияют вот на что: когда вы назначаете политику хранения виртуальной машине, у которой, например, выбран пункт "data-at-rest encryption" в качестве поддерживаемых сервисов хранилищ, то в качестве совместимых будут показаны только те хранилища, у которых реально предоставляется этот сервис со стороны оборудования. То есть эта вкладка нужна для того, чтобы обеспечить исполнение требований со стороны железа по сервисам перечисленным здесь (а именно: шифрование, компрессия, компрессия+дедупликация, размещение на гибридном/All-Flash хосте) для виртуальных машин, которым назначается политика.

То есть, Storage Rules - это поддержка тех сервисов, которые должны быть уже включены на ваших датасторах. Они работают именно на уровне vSAN Datastore и не применяются к сервисам данных (data services) на базе виртуальной машины или VMDK-дисков.

Недавно мы писали о новом продукте StarWind SAN & NAS от лидера в сфере программно-аппаратных хранилищ под виртуализацию - компании StarWind. Он предназначен для создания программных хранилищ на основе серверов с установленным там гипервизором.

Ну а на днях вышло еще одно новое решение - StarWind Backup Appliance. Оно, как можно догадаться, предназначено для резервного копирования виртуальных машин на хранилищах StarWind. Это программно-аппаратный комплекс на базе хранилища NVMe, который позволяет избавиться от проблемы производительности хранилищ резервных копий и забыть о задаче планирования окна резервного копирования.

Теперь бэкап на такое хранилище можно делать в любое время и без влияния на работу приложений и служб. За счет использования этого комплекса время резервного копирования у вас снизится минимум в 2 раза.

Более того, в случае сбоя вы сможете мгновенно восстановить виртуальные машины и файлы напрямую из резервной копии, обеспечив наилучшие показатели RPO и RTO по сравнению с традиционными решениями.

Модуль StarWind Backup Appliance поставляется в виде настроенного и готового к работе сервера резервного копирования, построенного на базе StarWind HyperConverged Appliance (HCA). Работа с продуктом происходит через удобный веб-интерфейс StraWind Web UI, есть также плагин StarWind для vCenter.

Высокая производительность и надежность решения достигается как за счет технологии NVMe, так и за счет отделения и изоляции сервисов резервного копирования от производственных данных. При этом сервисы бэкапа StarWind BA нагружают системные ресурсы только тогда, когда начинают выполнять задачу резервного копирования.

Важный момент, который стоит отметить - продукт Backup Appliance от StarWind поддерживается со стороны ProActive Premium Support, а значит, что ваша инфраструктура резервного копирования будет работать 24x7, даже когда вы в отпуске или спите.

Естественно, данные, находящиеся на хранилище резервных копий, надежно защищены с помощью технологий RAID и полностью отделены от сервисов, непосредственно реализующих резервное копирование. Ну а приятный бонус - это то, что вы можете выбрать один из следующих гипервизоров на модуле StarWind BA:

• Microsoft Hyper-V версий 2016, 2019 или 2022
• VMware vSphere версий 6.5, 6.7 или 7.0

На данный момент доступны 2 модели Backup Appliance (BA 30 и BA 60):

Как мы видим, обе модели представляют собой одноюнитовые серверы с 30 или 60 ТБ емкости (это полезная емкость после создания RAID) и 64 ГБ оперативной памяти на борту.

В качестве протоколов доступа к данным поддерживаются следующие:

• iSCSI
• SMB3
• NFSv4.1
• NVMe-oF

Ну и главное - в качестве ПО для резервного копирования используется лидирующий в отрасли продукт Veeam Backup and Replication V10 и V11. Тут можно быть спокойным - он работает надежно и быстро. В качестве системы мониторинга и отчетности можно использовать решение Veeam ONE.

Больше информации о решении StarWind Backup Appliance можно получить на этой странице. Живое демо продукта вы можете запросить вот тут.

На сайте проекта VMware Labs обновилась очередная интересная утилита Storage Performance Tester, которая позволяет провести тестирование хранилищ в один клик на сервере VMware ESXi, получив метрики IOPS, latency и CPU cycles per I/O. В новой версии появилась поддержка адаптеров vnvme, а также исправления ошибок для ESXi 6.7.

С помощью данного средства можно автоматизировать шаги проведения тестирования, которые включают в себя развертывание кастомизированной ВМ, запуск нагрузки по вводу-выводу внутри нее и, собственно, функции по анализу результата тестирования производительности.

Результаты для полученных метрик выводятся в графическом интерфейсе в виде диаграмм и комментариев к ним:

Самое приятное - это то, что утилита запускается одной командой, после чего пользователь получает итоговый результат. Выглядит это так:

#./sperf.py HOSTNAME -d DatastoreName

Данное средство можно использовать как для решения проблем с действующей инфраструктурой хранилищ, так и для выяснения максимальных параметров производительности только что купленного железа (диски, контроллеры, компоненты сети хранения данных).

Ну и видео о том, как это все работает:

Для запуска Storage Performance Tester вам потребуется:

• Python 3
• sshpass
• 2 ГБ свободного пространства на диске
• Linux-окружение (ядро не старше 2.6.31)

Скачать Storage Performance Tester можно по этой ссылке.